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(54) ACCESS CONTROL DEVICE AND RESOURCE PROTECTION METHOD IN DISTRffiUTED NETWORK SYSTEM 



(57) Abstract 

The present invention relates to a resource protection method in an open digital system in entities or processed by entities existing 
in a system such as the Internet in which resoiu-ces are physically and organically dispersed and independent entities are 
connected. In this open system, since in principle an entity has access to any resource of any of the other entities, caution is 
required to maintain privacy and, if necessary, conftdentiality by avoiding or minimizing a contamination and breakdown risk of 
the resoiut:es. Therefore, the protection of the resources is very important to assure the integrity and functions of the entities. For 
intelligent protection of these resources, especially for the protection from access without permission, an attachable and 
detachable guard, which accompanies variable-grained control and/or calls of files and/or services of a namespace (consisting of 
all names that are provided by the entities) is provided. 
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Specification 
Technical field 

The present invention relates to a method for protecting resources in entities or processed 
by entities in an open digital communication system that accesses these physically and 
organically distributed independent entities. In this open system, since in principle any entity has 
access to resources of other entities, it is very important to protect the resources so as to ensure 
the integrity and functions of the entities. As an example of this system, currently, there is the 
Internet provided with distributed stations, servers, and terminal user computers that provides or 
possesses resources such as data or program files. The present invention intelligently protects 
these resources, especially protects the resources from access without permission. 

Prior art 

Sharing of resources is a concept well known in many fields; however, the burden 
imposed on the maintenance of these resources can be distributed between groups by sharing rare, 
expensive, or infrequently-used resources. Along with the desire to share the resources, since the 
desire to protect the resources from use without permission has increased, the resource sharing 
usually means the resource protection. It is not surprising that the resource sharing and the 
resource protection are core issues in distributed network computers. As computers become more 
available and interconnected, the necessity of a means to protect the resources in these connected 
systems is further increased. This is requirement is crucial, especially for open networks such as 
the Internet. In this open distributed network system, it is essential and imperative to protect 
resources such as password files and individual data, or hardware resources such as file system 
space and conununication capacity, or services such as cipher services from access without 
permission. Here, the protection means both basic access to the resources themselves and the use 
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of the resources by accessed entities. In other words, the protection means both coarse-grained 
resource protection (for example, an entity can use a file system service) and fine-grained 
resource protection (for example, an entity can use a file system service but does not have access 
to a password file). 

The current access scheme to protect the resources in the distributed system depends 
upon an authentication-based technique that in most cases requires somewhat extensive changes 
in service-providing entities. For example, as described under the title of "Kerberos: An 
authentication service for open network systems" written by J.G. Steiner, B.C. Neuman, and J.I. 
Schiller in a pamphlet of the Usenix Conference Proceedings, February 1988, Kerberos requires 
an encr5q)ted ticket that is transmitted along with each service demand. A user receives 
authentication through a service by a special trusted ticket and can request a Kerberos ticket for 
other optional services to be called upon, which are designated so that the user may use the 
services. Although this system is safe, it is complicated, time-consuming, and increases traffic in 
achieving the intended purpose of the resource protection. More specifically, the Kerberos access 
scheme for resource protection is not transparent for a service-providing entity (in terms of 
visibility), and the calling entity itself must be visually checked even for a valid ticket from the 
called entity, which is a drawback of a discretion-type mechanism. Codes for implementing the 
entity must be provided with a call for each library, and an entity that forgets to examine the 
ticket validity may allow any caller to access the resource. In addition, once an attacker exposes 
a central ticket permission service, the attacker also has access to all the entities participating in 
the related distribution system. 

D.B. Clifton presented another solution for a resource protection task in U.S. Patent 
No. 5,469,556 under the tide "Resource access security system for controlling access to 
resources of a data processing system" patented in November 1995. Clifton introduced special 
objects of so-called descriptors for addressing resources such as memory address in hardware. 
Table sets are attached to each descriptor and control the access to specific resources. Essentially, 
these descriptors form visual addresses of resources and realize a fine-grained access control for 
the resources in a system (see Clifton patent, column 3, hues 34-37) 

Although the Clifton access scheme for resource protection does not show central 
vulnerability, unlike Kerberos, its resistance might be one of its drawbacks. The Clifton access 
scheme cannot be applied to a memory address translation system, that is, a distributed system 
bound to a single address space, in spite of the use of the descriptors. However, the distributed 
system, according to an actual definition, includes several address spaces connected to a kind of 
communication medium. In addition, since the Clifton solution is not transparent and users must 
use special descriptors, programs of the users must be coded accordingly. 
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Moreover, both the Kerberos and Clifton access schemes cannot process dynamically 
appearing resources during the run time of a system (and after a resource protection mechanism 
is set). In an environment in which an entity can enter a distributed system from the outside (for 
example, a Java applet entering from the Internet), dynamically generated resources exist, and 
these resources are also required to be protected. 

Therefore, the main objective of the present invention is to realize a resource protection 
mechanism applicable to a dynamic distributed system. Another objective of the present 
invention is to generate a transparent resource protection mechanism for an entity that wants to 
access a program and/or a resource to be protected. In addition, another objective of the present 
invention is to provide a dynamically expandable resource protection method for protecting 
newly generated resources during the run time. 

Sununary of the invention 

Resources to be protected from access without permission in a distributed system are 
usually possessed or provided by an entity such as a server or other processing stations. In 
principle, all entities are permitted to have access to optional resources of other entities in an 
open distributed system; however, as mentioned above, a security measure that protects 
prescribed resources and permits the access to the resources by only prescribed entities and/or 
under prescribed conditions is required. 

In the resources, there are disk space, files, network access, etc.; however, objects and 
methods provided by the objects themselves can also be included. In the distributed system, the 
access to these resources occurs through services or methods that are provided by the entities or 
objects. The concept of the present invention starts from an idea for reducing the access to 
resources or services. To call or use a service, both the name of an entity that possesses or 
provides the service and the name of the service itself must be known. In actuality, for the access 
to the service, its name is made to correspond to its position. Namely, the name is resolved. All 
the names that the entities know form a namespace of the entities, and similarly, all the entity 
positions of the system constitute an entity position space of the system. 

Therefore the underlying concept in the present invention, for example, controls a name 
resolution process, like the limitation of the visibility of services for entities, to control the access 
of the entities to the services. Another feature of the present invention is that this control is 
implemented, for example, by an intelligent interception manager to provide a variable-grained 
control of a namespace and a name resolution process. Another main feature of the present 
invention is to provide an attachable and detachable guard, and this guard is combined with a 
name, called before or after the name is used, and provided to protect fine-grained resources. 
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Utilizing one or more features mentioned above, a protection domain that can be 
dynamically constituted is generated, and the guard domain means a controlled limited 
environment, that is, a sandbox in which an object that can be dynamically constituted can be 
freely operated. An arbitrary inappropriate action effect is limited to the sandbox and cannot be 
propagated to the rest of a system. A reduction-oriented controlled entry, an escape point from/to 
the sandbox, and especially, finely adjusted shape and size can also be dynamically provided. 

Brief description of the figures 

Figure 1 shows an entity provided with interfaces and resources (the terms will be 
defined below). 

Figures 2a and 2b show a method for mapping a name and its object reference. 
Figures 3a-3c shows steps and modifications of the method of the present invention. 
Figure 4 is a block diagram showing the embodiment of the present invention. 

Detailed explanation of the invention 

Next, a general overview (A) of the features of the present invention will be explained 
first, and then an embodiment (B) of the present invention will be explained. Both of these are 
examples for an object-oriented distributed network system and are processed in a Java-based 
network environment. Java is a programming language and environment developed by Sun 
Microsystems Co., located at 2550 Garcia Ave., Mountain View, CA 94043-1 100, USA, and the 
term of Java is a trademark of this company. 

A. Overview of the principle 
Java environment: 

Next, several common terms that are related to a Java computing environment and used 
in the present invention will be listed and briefly explained. 

An "applet" is a Java bytecode typically loaded from a remote source and is usually not 
considered trusted. 

An "application" is a Java bytecode loaded from a local sotirce and is usually considered 

trusted. 

The "Internet" is a worldwide open computer network consisting of multiple different 
subnetworks. 

The "World Wide Web (WWW)" is an open subnetwork of the Internet. 
An "intranet" is a closed internal network and is often used as a subnetwork of the 
Internet within a company. 
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A "browser" is a computer software or environment for supporting browsing (surfing) in 
the World Wide Web and downloading and running applets. 

"Java bytecode" is a code generated by a compiler for JVM which will be mentioned 
below. Java Virtual Machine (JVM) is a virtual, though well-defmed, processor for running the 
Java bj^ecode. It is called virtual because the machine is realized with software. 

A "library" is a set of defined functions or classes that are used in a program. 

A "sandbox" is a playground in which the Java applets are confined. It is a runtime 
environment delineated by a boundary with defined entry and exit points (gates) (for its detailed 
explanation, see the following content). 

Sandbox security model: 

The so-called sandbox described by J.S. Fritzinger and M. Mueller of the aforementioned 
Sun Microsystems Co. provides a playground delineated by boundaries and gates defined for the 
Java applet. All the applets are confined in this sandbox. To access something that is outside the 
sandbox, the applet must pass through the corresponding gate. Similarly, any conmiunication 
with the applet must pass through a gate that can control and limit the passage. Typically, the 
applets are developed remotely. Typically, a user starts the downloading of an applet, and the 
applet usually travels on an untrusted public network such as the Internet. 

Whether or not the applet is trusted depends substantially on the following elements: 

- whether or not an applet programmer cannot prepare an antagonistic program, that is, 
whether or not a programmer is trustworthy; • 

- whether or not a complier that generates a bytecode according to the rules defined in a 
language specification is trusted; 

- whether or not a network is trusted because an intruder can damage or modify the integrity of 
an applet. 

An applet that is evaluated negatively with regard to any of the aforementioned items, is 
not considered to be trustworthy. 

On the other hand, independent applications are usually developed locally, that is, in a 
safe environment or they travel on a trusted network such as an intranet. Therefore, the 
application is usually considered trustworthy. However, it is insufficient to discriminate the 
applet and the application by only the black and white logic. Since the sandbox-type access 
scheme is applied only to the applet and is not applied to the application, the implemented 
security is limited to the applet. In addition, since the currently implemented sandbox is 
insufficient and incomplete, multiple defects are found. 

Usually, the sandbox is implemented in a browser. Since it is hard-coded without a 
interaction with the end user, it cannot be programmed. Therefore, it is a static model having a 
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fixed boundary and a fixed gate. The gate itself, that is, its position, its policy, or its existence 
cannot be changed, and only the decision of the gate can be changed. This model does not 
consider the origin of a downloaded code but generally discerns only whether or not the code is a 
local or remote program, that is, whether the code is the application or the applet. 

For example, the Java security model already implemented cannot separate the 
implementation of an appropriate security policy from a mechanism for implementing the policy. 
Since decisions that can be controlled by most users are hard-coded in the Java virtual machine, 
the known security model is static, and the implementation of a sandbox paradigm is insufficient. 
Surely, there is a limitation in receiving and applying this known model because a security 
feature cannot be constituted. 

The new security mechanism for an object-oriented system of the present invention can 
be directly applied to the Java environment. In this chapter, some of essential terms have well- 
accepted definitions, whereas some of them are used in a specific manner in this explanation. For 
the consistence of the term use, these terms will be briefly defined below. 

Terminology: 

"Objects" includes data and provides a method, and the data can be accessed only by this 
method. Objects are dynamically generated. Namely, they are momentary. 
"Classes" are definitions for the objects and are static. 

"Entities" are considered as objects or reference classes, regardless of whether they are 
active or passive. The entity possesses or provides resources. 

"Interface" consists of a set of entity data and a method of an entity in which a service is 
accessed and changed. 

"Name" is a symbolic reference for the method of an entity, and the name is not 
understood, that is, interpreted by a runtime element of a runtime system. 

"Object reference" is a pointer for the position of the method of an entity, and the object 
reference is understood, that is, interpreted by a runtime environment of the runtime system. 

"Service" is considered as a method of an entity indicated through one of an object 
reference and a symbolic reference. 

Present invention: 

The objective of an original security mechanism is to protect resources from access 
without permission in an object-oriented system. This security mechanism can be used for audit 
and can monitor usages of resource utilization, as well as access control. Its design is based on 
the basic assumption that if the access to resources is strictly controlled, none of programs are 
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damaged. The following elements are essential, alone or in combination, for the security 
mechanism of the present invention. 

Object-oriented paradigm: Data are included in the entity and can be modified only by a 
provided interface. The access scheme to protect the entity data is to control the access to this 
interface. 

Lazy object binding: Each symbolic reference (or name) is replaced with the 
corresponding object reference, through which a service can be called, at a run time. This 
replacement process is intercepted by the security mechanism of the present invention. 

Name resolution: To obtain an object reference for a given name (symbolic reference), a 
name resolution is required. In this name resolution, the name is made to correspond to the object 
reference. In the original mechanism of the present invention, this correspondence can be 
intercepted by an interception manager that controls the name resolution. 

Guard object: It can be optionally attached to an object reference. This guard is called 
before and/or after the object reference is used. In addition, it has access to context information. 

Object-oriented paradigm: 

A resource is included in an entity and can be accessed only through a provided interface. 
Therefore, in an object-oriented system, to protect the resource from access without permission, 
an access control issue on such a resource can be limited to an access control problem on an 
interface of the related entity. The entity can also provide different resources, thus being able to 
provide different interfaces as shown in Figure 1, To use a specific resource, the name (and the 
position) of the resource must be known, and the name must be changed into an object reference 
for indicating the position where the corresponding method exists. 

Lazy object binding: 

Binding is a process for connecting required elements of an executable code. The 
elements are generated by a compiler and called object files. The object file is provided with 
symbolic references for other object files. A linker connects these object files together to replace 
the symbolic reference with the corresponding object reference. At that time, the executable code 
possesses an understandable, that is, interpretable, necessary object reference by a runtime 
environment, so that the executable code can call a reference method. 

If the replacement is carried out at runtime, it is called "dynamic binding," and otherwise, 
that is, if the replacement is carried out before the execution of the code, it is called "static 
binding." 

If all the symbolic references are replaced at one time, the connection process is called 
"eager binding." An object reference for a symbolic name is carried out only once for a run time. 
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it is called 'lazy binding." Once the replacement is carried out with executable code, it is fixed 
and is no longer subject to change. 

For example, C++ compiler forms additional symbol information by combining a human- 
readable symbolically referenced method of another entity (that is, name), with its pattern 
information. Any of these references is still a symbol (that is, name); however, it is no longer a 
human-readable format. A binder includes an appropriate code in accordance with a symbolic 
reference and replaces the symbolic reference with an appropriate object reference. The object 
reference indicates the start of the position where the method exists. The Java environment uses a 
lazy binding access scheme. Once the runtime environment uses each symbolic reference, the 
symbolic reference is replaced. 

In a distributed access scheme, a method through an address space and/or a system can be 
invoked. In most cases, a remote object is expressed by a proxy object that acts as a local 
representative. Usually, the proxy object searches for the remote object and generates, destroys, 
and invokes the remote object. Therefore, the object reference indicates the position of the 
corresponding proxy object. 

Interception and name resolution: 

The feature of the original mechanism of the present invention is that the binding process 
is intercepted, regardless of the eager binding or lazy binding, and an interception manager is 
inserted. The resolution of a symbolic reference, that is, a name requires the correspondence 
between the latter and an object reference. The process for finding the corresponding object 
reference for a given symbolic reference (name) is a name resolution process. It is implemented 
by the name resolution process as shown in Figures 2a and 2b. To employ a specific method, an 
invoking object must know a symbolic reference or name to be resolved with an appropriate 
object reference. If the entity does not know the symbolic reference or name, a reference and an 
entity, which are expressed with the symbolic reference, reliably know the symbolic reference or 
name, and references that are expressed by the object reference are separated, the following two 
difference spaces are generated. First, a "presumed namespace (concrete namespace)" of the 
entities consists of a set of symbolic references. Although these symbolic names are not yet 
resolved, they are subjected to the resolution process. The entities presume that these references 
exist; however, this presumption has not yet been verified through the resolution process. Their 
methods can neither yet be invoked nor understood by a run time and a runtime element. 
Secondly, a "concrete namespace" of the entities consists of a set of object references. Since 
these object references are resolved names and have been verified through the resolution process, 
the entities clearly know them. The object references can be understood by a run time and a 
runtime environment. 
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The set of methods indicated in the "concrete namespace" is usually a subset of the 
methods indicated in the presumed namespace. Although the references (object references and 
symbolic references) are different, the methods indicated by them are the same. 

Interception manager: 

A so-called interception manager shown in Figure 2b is one feature of the present 
invention that can optionally be provided. When the interception manager is provided, its main 
mission is to control and correct the name resolution process according to a specific security 
policy. For example, the concrete namespace can be reduced by blocking the resolution of 
several symbolic names. If the name resolution process is intercepted and the interception 
manager is inserted, an access control mechanism is constituted. The regulation of the concrete 
namespace for the security purpose is based on the assumption that none of resources can be 
used without being provided with an object reference of an entity that represents the resources. A 
symbolically referenced method is resolved only when the interception manager permits this 
resolution. 

As shown in Figure 2b, the interception manager is part of the name resolution process. 
The object reference as a result of the name resolution process is intercepted, and the interception 
manager delivers a notice that an unmodified object reference or an object reference attached 
with a guard object or an exceptionally referenced entity does not exist. The density of the access 
control implemented by the interception manager depends upon the density of the resolution 
process. More precisely, the interception manager can act at a coarse level instead of a fine level. 
Nevertheless, a variable-grained access control still exists. The interception manager accesses 
context-sensitive information such as source entity name, destination entity name, and their data. 
The control of only the access is insufficient in certain cases, and auditing or monitoring the use 
of resources may be required. This requires a further invoking of a security mechanism element 
before and/or after protected resources are used. This object is called a guard and can be inserted 
by the interception manager. 

Guard object: 

A guard object as another optional feature of the present invention is combined with a 
specific object reference, and it is called before and/or after the object reference is used, 
depending upon how the interception manager installs the guard object. 

Before a related object reference is used, if the guard object is called and accesses an 
argument provided for a destination entity, it is said that the guard object has been installed 
before the destination entity. After a related object reference is used, if the guard object is called, 
the called message is delivered, and the guard object accesses the delivered value, it is said that 
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the guard object has been installed after the destination entity. Figure 2b shows a modified object 
reference attached with the guard object as one of the delivery results of an intercepted name 
resolution process. 

If there is no error in the guard object, the implementation is continued normally. 
Similarly to context information used by the interception manager, the guard object also accesses 
context-sensitive information. Source entity name, destination entity name, and call parameters 
are included in the information. Before the guard object is installed before the destination entity, 
the following actions are carried out: 

- a call is refused. 

- a call is passed through without changing it. 

- a call is changed into provided data. 

- the destination of a call is changed. 

- the rights for a caller entity are assigned and/or checked. 

- the access is monitored. 

- a notification and/or an audit monitoring service is carried out. 

If the guard object is installed after the destination entity, the following actions are 
carried out: 

- a delivery parameter or state is changed. 

- a prior assigned right is removed. 

- a response is monitored. 

- a notice and/or an audit monitoring service is carried out. 

The guetrd object is not affected by a source or destination, that is, a calling entity or an 
entity to be called. The reason for this is that it is attached from the outside by the interception 
manager. 

Regarding the invoking entity or the entity to be called is concerned, the guard object 
cannot call it, and it is transparent. Contrary to the interception manager, the guard object cannot 
directly reduce the concrete namespace and can have only an indirect influence on the 
namespace. However, the original symbolic reference can be formed by inversely resolving the 
attached object reference. As a result of this inverse resolution, when this method is used next 
time, the symbolic reference is run into again, followed by a call for the name resolution and the 
interception manager. The interception manager has a possibility of re-modifying the concrete 
namespace of the call object according to the security policy. The inverse resolution of the object 
reference is useful for the case where the security policy is changed after the symbolic reference 
is resolved. 
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In addition, each guard object has a possibility of determining how long the guard object 
wants to be attached to the object reference. The guard object can be determined so that it is self- 
separated, and in this case, it is no longer invoked by the call of the object reference. 

Capability: 

The capability is a right to call a specific object in a specific mode (it will be explained in 
further detail later). In a book titled "Modem Operating System[s]" by A.S. Tanenbaum, 
published by Prentice Hall International Co. in 1995, the following three elements can be 
included. 

(1) Pointer to objects: A necessary pointer is achieved by a resolved reference (object 
reference). If executable code is provided with the pointer, it is assumed that an appropriate 
runtime system can be called. This means that all the entities having a capability can call the 
corresponding method. 

(2) Pattern information of objects: Required pattem information is achieved through an 
attached guard object. The pattem of the capability depends upon a related guard object. 

(3) Access right for objects: A required access right is achieved by an attached guard 
object. It can check the right, and a calling entity must provide a right to use a specific method. 
In addition, if the calling entity is provided with an appropriate right, a guard object reinforces 
the existing right or can also assign a new right to utilize this service. 

The capabilities of an object reference and a guard object are similar, but they are not the 
same. A resolved name provided with an installed guard object may be regarded as an improved 
dynamic capability. The dynamic element of the capability is a bound guard object. 

Overview summary: 

The access scheme proposed to protect resources in an object-oriented system includes 
one or more of the following features. An object-oriented paradigm well controls the access to 
resources through an object and its interface. Access control is achieved through the control of a 
namespace for a calling entity to control the visibility of a resolved name. If the calling entity 
cannot view a service, the entity cannot call the service and cannot use related resources without 
the possibility of calling a method. Since a resolution manager (and a guard object in accordance 
with the selection) may utilize context information, the resolution manager can act very flexibly 
and is dependent on contexts. Even if an entity is not known, the guard object can be attached 
from the outside and is invisible and transparent as far as a calling entity and an entity to be 
called. Therefore, the mechanism protects resources in a dynamic form at low cost in terms of 
performance burden. 
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B. Embodiment 

Next, the embodiment of the security mechanism of the present invention will be 
described in the Java environment. All the changes made for the Java Virtual Machine (JVM) 
including an interpreter and a runtime library will be investigated. In addition, the elements of 
the security mechanism element of the present invention realized in Java will also be presented. 

In this chapter, since the detailed contents of the embodiment are handled, it is assumed 
that any party concerned is familiar with the basic mechanism of the embodiment in JVM and C 
as well as the Java programming language itself. The comprehensive presentation on the Java 
language and the embodiment in JVM are described in a book titled "The Java Language 
Specification" by J. Goslin and G. Tele and a book titled "The Java Virtual Machine 
Specification" by T. Lindholm and F. Yellin published by Addison- Wesley Publishing Co. in 
1996. The embodiment elements of the security mechanism of the present invention are based on 
Java Development Kit (JDK) version 1.0.2 and the AIX version of JVM. This chapter describes 
the elements of protection system resources expressed with a system class. Though a slight 
change in the Java virtual machine was inevitable, the change was maintained to be as minimal 
as possible. 

Bl. Function overview 

The embodied function of the security mechanism of the present invention includes the 
embodiment of an intercept manager and several basic guard objects. The term of the entity has 
been explained in detail in the previous chapter to apply the entity to a specific class. The class 
can be regarded as an entity because it possesses and indicates resources. Since system resources 
are expressed through the corresponding system classes in the Java library, the class is not 
ambiguous but is known as a sufficiently officially recognized name. Therefore, this embodiment 
protects the system classes existing in the Java library. An object reference received from a name 
resolution process (see the following) is a pointer to the corresponding part of the code that 
substantially indicates the start of a method description. 

The protection of the system classes is achieved through the access control by modifying 
the namespace. If the concrete namespace of an object includes an object reference, the 
subsequent access to a referred method is permitted. Therefore, as described in the above 
assumption, a program has access to only resources that can utilize the object reference. To 
control and modify the concrete namespace of the object, the lazy binding mechanism and the 
name resolution are utilized by inserting the intercept manager as mentioned above. The guard 
objects are bound with the object references. In order to call the guard object before the original 
method is implemented, the method call technique is expanded so that it is provided with an 
examination of the installed guard object. To realize this fiinction, the following subjects: 
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- resource protection through a namespace, 

- change of a method call element in the Java virtual machine, 

- intercept information base class that accesses the original C code, 

- realization of an intercept manager, and 

- guard object base class 
are very important. 

B2. Java virtual machine change-system level 

In this section, the reinforcement of the Java virtual machine and the Java runtime library 
will be discussed. The reinforcement is realized in the original C code. Therefore, it is machine- 
dependent. To realize the security mechanism of the present invention, the following elements: 

- name resolution element of the virtual machine, 

- all opcodes that handle a method call, 

- binary method expression in memory, and 

- thread structure 
were changed. 

Namespace modification: 

Access control is achieved, and as a result, to achieve the resource protection, the 
concrete namespace of a called object is controlled and reduced or expanded. 

To modify the namespace of a starting object, the lazy object binding method of Java is 
employed. The binary file layout of Java refers to other classes and interfaces and their fields, 
methods, and preparers symbolically by utilizing sufficiently officially recognized names. For 
the fields and the methods, these symbolic references include the names of class or interface 
patterns for declaring the fields or methods along with appropriate pattern information as well as 
the names of the fields or methods themselves. Before the object is usable, its name must be 
resolved and become an object reference. An identifier verifies whether or not the object 
reference is correct. Typically, if the reference is repeatedly used, the object reference is replaced 
with a direct object reference that can be more efficiently processed. If an error is generated, an 
exception occurs. For more details, refer to a book titled "The Java Language Specification" by J. 
Goslin, B. Joy, and G. Tele and a book titled "The Java Virtual Machine Specification" by 
T. Lindholm and F. Yellin published by Addison-Wesley Publishing Co. in 1996. 

After the name is resolved into an object reference, the intercept manager is called to 
determine whether or not the resolution of a symbolic reference is allowed (see Figure 4). 
Therefore, the name resolution is intercepted, realizing the lazy object binding. In accordance 
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with the return value of the intercept manager, a concrete namespace is modified as described 
below. 

If the intercept manager returns "false," a NoClassDefFoundError exception is provided, 
indicating the absence of a class file to a called object. Therefore, the name of a desired resource 
cannot be resolved, so the position of the corresponding part of the code is not known. This 
technique that inquires of the intercept manager and then provides an exception reduces the 
concrete namespace of the called object. 

If the intercept manager returns "true," the call continues normally, and the concrete 
namespace is not modified. In actuality, the concrete namespace is expanded as a resolved name, 
that is, as a pointer to the corresponding part of the code provided with an object reference. 

The following code segment CI illustrates the new code inserted into a name resolution 
function. This C code segment carries out the following steps: 

(1) A required structure is initialized to manage a guard object. 

(2) Whether or not a required resolution is permitted is checked, and if it is not permitted, 
a non-resolution is indicated, and "false" is returned. 

(3) Otherwise, the method is indicated by a resolution, and the symbol information is 
replaced with the pointer to the corresponding part of the code. 

Since the intercept manager can attach several guard objects, the method call technique 
requires the modification as well as the name resolution process. 
Code segment CI : 

This code segment was inserted into a function for resolving the symbolically referred 
name. An appropriate exception is provided to the ic_CheckMethodResolving( ) method (in this 
code, the guard object is called a "filter object"). 

[Resolution method] 
/* 

If the corresponding method expression can be found, a filter delivery table for this 
method is prepared. 
*/ 

ic_PrepareFilter (class, mb); 
/* 

Whether or not this specific name resolution is permitted is checked. 
*/ 

if (!ic..CheckMethodResolving(mb)) { 
/* 

If the resolution of this method is not permitted, it is indicated as a non-resolution. 
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*/ 

fieldfiltertable(&mb->fb)->resolved = FALSE; 

return FALSE[;] 

} 

/* 

The method is indicated as a resolution. 
*/ 

fieldfiltertable(&mb->fb)->resolved = TRUE[;] 
[/*] 

The symbolic name information is changed to a pointer to an appropriate method block. 
*/ 

constant_pool[index].p = mb; 
continue_as_usual( ); 

[...] 

Method call: 

The Java interpreter is in charge of running a method that has already been resolved. A 
detailed discussion on the method call and the related procedure is described in a book titled 
"The Java Virtual Machine Specification," by T. Lindholm and F. Yellin, published by Addison- 
Wesley Publishing Co. in 1996. Figure 4 shows a brief summary of a control flow of the method 
call. In Figure 4, ten new elements added by the present invention are 19-25 and 27-29, and the 
other elements are the original Java elements. The new elements of the present invention include 
the check on the name resolution and the implementation of guard objects. 

opcode: 

opcode is a short term showing the operation of a specific set and is usually a number. It 
represents a specific function. For example, opcode 182 (0xb6), related to an associative memory 
code opc_invokevirtual, shows a basic step for calling a virtual method. A detailed explanation 
of various Java codes and functions which are provided by these codes can be found in the 
aforementioned book by T. Lindholm. To install and maintain the guard objects, the embodiment 
of the opcode for handling the method call is changed. The function is expanded so that a code 
for checking the guard objects and its subsequent execution is provided. After the last guard 
object is executed, the original method is executed. C2 is a C code segment inserted into all the 
opcodes that handle the method call. This code segment carries out the following steps: 

(1) A step for checking whether or not the guard object is installed and continuing 
execution normally if there is no installed guard object. 
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(2) A step for checking whether or not the method is resolved and calling an installed 
guard object if the method is resolved, and 

(3) A step for checking whether or not an exception is handled, stopping execution of the 
method if the exception is provided, and handling the exception. 

To attach the guard object to an object reference, the memory layout of the original 
method is expanded. 

Code segment C2: 

This code segment is inserted before execution of the original method. 
[Execution method] 

/* 

Is a filter delivery table installed? 

If it is installed, whether or not a filter object is installed is checked. 
*/ 

if (fieldfiltertable(&mb->fb) && 

(fieldfiltertable(&mb->fb)->used_filter)) { 

/* 

Is this method resolved through the mechanism of the present invention? 

*/ 

if (fieldfiltertable(&mb->fb)->resolved == TRUE) { 
/* 

* The installed filter object is called. 
*/ 

ic_InvokeFilterObjects(fieldfiltertable(&mb->[sic; omission in source]), ee); 

} else { 

/* 

The namespace is checked and an intercept manager object is called. 
*/ 

ic_CheckMethodResol ving(mb) ; 
} 

/* 

Is everything all right? No exception has been provided to anyone. 
*/ 

if (exceptionOccurred(ee)) 

goto handle_exception; 

} 
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continue_executing_original_method( ); 

[...] 

Method expression: 

In order to execute an arbitrary method of an object, the method requires the 
corresponding binary expression in memory. The binary expression of the method is divided into 
a static element and a dynamic element. The static element includes its class depiction and static 
field, and the dynamic element includes its dynamic field. A text segment and a data segment of 
the binary expression executable in a UNIX operating system are similar concepts, and two 
segments correspond to different regions of an address space. The text segment corresponds to a 
read-only mode, and the data segment corresponds to a read/write mode. 

The static element of the method is shared by all the objects instantiated from the same 
class depiction; however, each object has its own dynamic element. The guard object is attached 
to the static element (fieldblock structure) of the method. Therefore, the guard object is also 
shared by all the instances of the same class description. Though the guard object is attached to 
the static element, the guard object is attached to a different object and its method rather than 
being attached to a class and its method. 

Guard delivery table 

A guard delivery table manages the attached guard object. It has the references of each 
guard object and shows how many guard objects are installed. A header consists of the following 
management elements: 

a variable (indicated by used_filter) showing how many guard objects are used, 

a variable (indicated by res_filter; however, it must always be established that res_filter is 
greater than used_filter) showing the number of guard objects to which a space is allocated, 

a flag (indicated by resolved) showing whether or not it is considered that the method is 
resolved, 

a pointer (indicated by mb) to an attached method expression, 
a pointer (indicated by caller) to a class filter of a calling object, and 
a pointer to the first element of a dynamic array including a guard object structure that is 
managed. (For historical reasons, the guard object is called a filter object in the code.) 

The next code segment C3 illustrates the structure of the guard delivery table header. 

Code segment C3 

It is a header of the guard delivery table, 
struct filterdtable { 
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int used_filter; 
int res_filter; 
int resolved; 

struct methodblock *mb; 
struct ClassClass *caller; 
struct filterdesc *filters[l]; 

}; 

The pattern of the array element indicated by filters is illustrated in the code segment C4, 
and it includes the following elements: 

a pointer (indicated by obj) to an object memory position of the guard object, 

the method (indicated by methodname) of a method to be called, 

the corresponding signature (indicated by signature) because two methods can have 
different signatures, though the name is the same, and 

an answer call method name (indicated by notify) for designating a method in an 
intercept manager class called when the guard object separates itself from the corresponding 
object 

Code segment C4: 

Each element in the filter delivery table is an instance of filterdesc. 
struct filterdesc { 

HObject *obj; 

char * signature ; 

char *methodname; 

char *notify; 

}; 

Since the guard object is realized by Java, it is a latent candidate for the guard object that 
modifies the namespace and is attached. Therefore, to avoid the repetition problem, an executing 
thread indicator is attached. 

Thread: 

The thread is an execution path in an address space. This address space can be shared by 
many methods that are currently running. A detailed discussion on the thread concept is shown in 
a book titled "An Introduction to Programming with Threads" by A.D. Birell, described in the 
System Research Center (SRC) Report from Digital Equipment Corporation issued on January 6, 
1989. 
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The guard objects and the intercept manager of the present invention are implemented in 
Java. Since they also access resources, a criterion for discriminating elements belonging to the 
mechanism of the present invention from elements that do not belong to the mechanism is 
required. Otherwise, each time the intercept manager accesses resources and calls the method, 
the intercept manager itself checks the elements. This repetition can disappear if the thread is 
appropriately indicated. If the thread enters the guard object or the intercept manager, it is 
indicated that the thread is in a supervising state. Next, if the thread makes an attempt to enter the 
guard object or intercept manager, whether or not the thread is indicated in a supervising state is 
checked. In accordance with the existence of this indication, the system determines whether or 
not the thread is applicable to a new mechanism. If the guard object or intercept manager leaves, 
the pointer is erased. 

This temporarily allocated state is similar to the system call concept of traditional UNIX, 
in which the process that invokes a system call has more rights to access resources than the 
process that does not invoke a system call, to some degree. In kernel mode, a supervising state is 
temporarily allocated to an invoking process. With this privilege, the process accesses protected 
resources possessed by the operating system. When the process leaves the system call, the 
privileged state is erased. A detailed explanation of the system call concept is described in a 
book titled "4.4 BSD UNIX Operating System" by S J. Leffler et al., published by Addison- 
Wesley Publishing Co. in 1996. 

The guard objects and the intercept manager also have access to context data, including 
arguments provided by the original method, and modify the arguments. If the call of the original 
method is intercepted and the intercept manager is requested or the guard object is called, the 
invoking thread is temporarily allocated a pointer to the stack frame of the original method. 
Therefore, the pointer accesses the method argument situated on the stack. 

When entering the security element according to the present invention, a pointer to an 
appropriate guard delivery table is allocated to the invoking thread. Therefore, the thread 
completely accesses all the guard objects. 

In order to achieve the aforementioned function, the thread structure is expanded so that 
it is provided with the following elements: 

- a single bit (indicated by sv_thread) showing whether or not the thread is in a 
supervising state, 

- a pointer (indicated by iv_filtertable) to an appropriate guard delivery table, and 

- a pointer (indicated by icoptop) to an appropriate stack frame of the original method. 
These elements are allocated when the thread runs across the boundary between ordinary code 
and security code. 
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Java class layer-user level: 

In this paragraph, elements embodied by Java will be described. Embodying a new 
security mechanism by Java follows one of the main principles of the Java philosophy, that is, 
"portable, if possible/' 

Therefore, most of the embodiments are implemented in Java using an interface well 
defined for the elements embodied in the original C code. A routine embodied with the original 
C code can be accessed through an abstract base class called Interceptionlnfo. 

Intercept information: 

Interceptionlnfo is an abstract class implemented in Java. It is utilized for providing a 
basic security function of the present invention. A discussion on a class modifiers in Java is 
provided by Goslin et al., cited above. The elements of this base class can be divided into the 
following categories: 

- installation management of an optional guard object, 

- removal management of an optional guard object, 

- sequence management of an installed guard object, 

- fetch and modification of an optional argument, and 

- fetch of sufficiently officially recognized names, method names, and signature names of 
called object/entity and object/entity called. 

The overview of an Application Programming Interface (API) provided by the 
Interceptionlnfo base class is provided from the code segment C5. To obtain a sufficient security 
function of the present invention, the intercept manager class and all the guard objects must sub- 
class this Interceptionlnfo base class as shown in the figure. 

Code segment C5: 

This class provides an interface for the embodied original C code, 
public abstract class Interceptionlnfo { 

protected native void unresolveMethod( ); 
protected native int getlntArgument (int index) 

throws ArgumentAccessException; 
protected native void setlntArgument (int index, int value) 

throws ArgumentAccessException; 
protected native float getFloatArgument (int index) 

throws ArgumentAccessException; 
protected native void setFloatArgument (int index, float value) 
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throws ArgumentAccessException; 
protected native byte getByte Argument (int index) 

throws ArgumentAccessException; 
protected native void setByte Argument (int index, byte value) 

throws ArgumentAccessException; 
protected native Object getObjectArgument (int index) 

throws ArgumentAccessException; 
protected native void setObjectArgument (int index. Object value) 

throws ArgumentAccessException; 
protected native void printArgument (int index); 
protected native Object getClassLoader( ); 
protected static native String getCaller( ); 
protected static native String getCallee( ); 
protected static native String getMethodName( ); 
protected static native String getSignature( ); 
protected static native boolean 

pushFilter (InterceptionPilter arg. String filtermethod, 
String filtersignature. 
String ic_manager_notify); 
protected static native boolean popFilter( ); 
protected static native Object[ ] getFilterList( ); 

} // Class Interceptionlnfo 

Intercept manager class: 

The intercept manager is embodied by Java and is regarded as final and static. The 
intercept manager sub-classes the Interceptionlnfo base class. It is in charge of controlling and 
modifying the namespace of a calling object. The intercept manager embodies a security policy 
for the Java environment, regardless of whether the call entity is part of the application or part of 
the applet, that is, without discriminating between the application and the applet. The intercept 
manager defines the boundary of a security sandbox and implements a gate for communications 
with the outside of the sandbox. 

Since Java itself manages memory, its garbage collection is responsible for removing an 
unused object and freeing the memory. In case no reference exists at Java level, it is regarded 
that the object is not in use. Therefore, the intercept manager must track and monitor all the 
guard objects generated and installed by the intercept manager. Otherwise, when memory is 
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freed, the garbage collection removes this object. A detailed discussion on garbage collection is 
provided from the above-cited book by Lindholm. The intercept manager generates guard objects 
and determines a certain guard object that is attached to a certain method. The manager also 
designates the sequence by which the guard objects are called before and/or after the original 
method. 

Intercept filter: 

The InterceptionFilter class provides a basic function required by a guard object. Like the 
intercept manager, the InterceptionFilter class is sub-classed to access the original C code 
method. This class expands the sub-class by a method for separating the sub-class from the 
original method (object reference attached to the class). In an actual embodiment, the guard 
object is executed before the original method is called. The code segment C6 shows a basic 
guard object base class. The defaultCallFilter( ) method is a method for calling an object 
reference as a default before it is called. 

Code segment C6: 

It expands the Interceptionlnfo abstract base class, 
public class InterceptionFilter extends Interceptionlnfo { 

protected int unresolve; 

private protected InterceptionFilter( ) { 
unresolve = 0; 

} 

private protected void defaultCallFilter( ) { 
throw new ICFilterException ("no filter method 
implemented"); 
} 

private protected native void detachMySelf( ); 

} 
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Conclusion: 

This chapter B has handled a core subject called the embodiment of the concept 
expressed in the chapter A. An essential function for implementing the security mechanism of 
the present invention was described as a subset of the architecture proposed. This architecture 
addresses the principle of controlling access to a system class representing a system resource and 
calling an optional guard object 

The modification in the Java virtual machine was limited to the minimum. In order to 
modify the concrete namespace of a called object, a significant change was made in the name 
resolution process, and a significant change was also made in the alternative or selective name 
resolution process through the guard object, so that the security for all the method calls can be 
assured. Because of the intercept manager and all the guard objects, a programmer can constitute 
a variable-grained protection mechanism, which can be optimized in terms of desired protection 
level as well as economy. 

Claims 

1. A resource protection method in a distributed network system, wherein in a resource 
protection method for protecting resources (2a, . . ., 2n), such as files or other objects, in a data 
processing system provided with a name resolution mechanism, especially in a distributed 
network system, said resources are called by a first entity, that is, a calling entity (7) and 
provided by a second entity in said system, that is, an entity (9) to be called; 

access to said resources is called by said calling entity (7), utilizing symbolic names, in 
which all the symbolic names form a presumed namespace for the entities; 

said name resolution process allocates object references to said symbolic names, in which 
all the object references form a concrete namespace for the entities that reflect permitted 
resources; said permitted resources are a subset of all the resources of said system; and 

said calling entity (7) receives permission to access only said concrete namespace in said 
entity (9) to be called. 

2. The resource protection method in a distributed network system as cited in Claim 1, 
wherein said symbolic name includes at least an entity name and a method name; and all of said 
names form said presumed namespace. 

3. The resource protection method in a distributed network system as cited in Claim 1 or 
2, wherein if said access is allowed, said name resolution process accesses the resources (2a, . . ., 
2n) by calling a desired method from the entity (9) to be called, resolving the symbolic name by 
an object reference (6) for permitting the access of the calling entity (7), especially an immediate 
access. * 
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4. The resource protection method in a distributed network system as cited in any of 
Claims 1-3, wherein said problem resolution process is modified by providing a guard object (13) 
and replacing said guard object (6) with a reference to said guard object. 

5. The resource protection method in a distributed network system as cited in Claim 4, 
wherein said guard object hides said object reference (6b) from said calling entity (7) to provide 
conditional access to a desired method and to control said call process. 

6. The resource protection method in a distributed network system as cited in Claim 4 or 
5, wherein the guard object is called before or after the object reference is used. 

7. The resource protection method in a distributed network system as cited in Claim 4 or 
5, wherein the conditional access provided by said guard object depends upon a more detailed 
analysis, compared with the fine breakdown, that is, a breakdown used in the name resolution 
process. 

8. The resource protection method in a distributed network system as cited in any of 
Claims 1-7, wherein at least one step of said method is realized in an object-oriented mode. 

9. An access control device in a data processing network, wherein in an access control 
device for resource protection including a means for protecting resources (2a, . . ., 2n), such as 
files or other objects, from access without permission in a data processing network, said access 
control device, in which said resources are called by a first entity, that is, a calling entity (7) and 
provided by a second entity in said network, that is, an entity (9) to be called, includes 

a symbolic name resolution means for resolving a symbolic name that is used in invoking 
the access of said resources by said calling entity (7), in which a presumed namespace is formed 
for the entities by all of said symbolic names; 

an object reference allocation means for allocating object references to said respective 
symbolic names, in which a concrete namespace that reflects permitted resources is formed and 
said permitted resources are a subset of all resources; and 

an access limitation means for limiting the access of said calling entity (7) to said 
concrete namespace in said entity (9) to be called. 

10. The access control device in a data processing network as cited in Claim 9, wherein 
said device further includes a means that installs a guard object (13) and replaces said object 
reference (6) with a reference to said guard object. 

1 1. The access control device in a data processing network as cited in Claim 9 or 10, 
wherein at least one of said means is realized by software in an object-oriented mode. 

12. A data processing network wherein the method of any of Claims 1-8 and/or the name 
resolution system of any of Claims 9-11 are realized. 
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#e ^Hj^of Bi?a oi^oii cnoh ^A\m sie :^Hxiib oj^ sexfoii:?iiu n xmm moh ^ 

m^m ^o\q. ^^x\?i ej^ Aidi^^e in#Ai?i Bieis, a ^^xj^ £e§^ 

= ^S(0. 8. Clifton)^ 1995^3 ll^OII ^o\^ Resources access security system for controlling 
access to resources of a data processing system ' OlEf^ D|^ ^^ X|| 5.469.556 ^0||A| 

a^ 3fW|0|| CH^^ EEQE 5Ha# XIIAimSia. M^^B ShH^IOi LH0l|A|2J Di) S^l OiHai^Sf ^B XhS 

m oi^ai^m:^! ^iE[. 4:?! q:dt3^Ei(descriptor)efb ^^si ^M\m ±:>mQ. mo\m M\^y\ ^ q 

^3^Eioil ¥^^E|Oi xmm Oi^ mEm xiioiehq. o| q^^s^eib xm^ 

m g^moi Al^^' LH2I X[^Oi\ CHo^ DIAII XllOlg ?S£^q(Mg^ column 3. 34-37 M 

^ mee ^^^^ 

xm ase ^^s^ ^^^^o| ^isbi|^><2^ ^o^^s ^oixi^ &^xiEt. 01 LH^oi n 

om:?j £|7|£ onif. q^3gqg AFg^^oiis M^mn oiieei oisairi: 

Dimue. ^ eg! oingi^ 52}oii ^^goi mti ai^^^oh^ ^ aiq. aau. 
A|>ig|s ^^1^ gojoii oj5^2 gj^o| oHxii^ ^® oisai^ gzte Hil£[q. ses^. 

5H0^ §hq- 

SEE^. ^i^mis^ ^^eie Ai^i]2] ^"^aizi mimm x\m as Dimueoi 

^)oi| e^^^ uqq^ xm^ m^m ^ giq. :>m?\ £l¥^¥&i Mii^ ai>^^ o^o^ ^oi^ ^ 21^ 
^s(oiie mo\ e.iEf'jyo^^Ei eois^ xhuj oH#^)oiiAi. e^n^ xmoi ^xHrnm oie x\m 
oil cH6HAi£ mQiy\ ?iq- 

m^M, ^ §^ Ai>^a|oii x^g as oii^uge ^sm^ ^oiek 

^ ^S2i Etqe H^a^ asi xfgoii mm^ nnm Q\m x\m a 

s oii^iqg^ ^^m^ 3ioiq. ^ ^ssj sEmusj bf^^m:Hi^ ^i^Aiei ^011 dff^ 



A|^9j LHOilAf Se^S^EI aal X^gs oj|s B| ^E110|ij3| ^ 

e :>H^loii 2|6H ^^£i>iq SEb xfi^siq. ^^^k :)mm^\ Ajr^^noflA-i :^Hxii:?[ qe :>m\^ 
ojojoj ;^^goii ^Em ^ my\^x\oy. ^o\, ^^21 x[^m ^s.o\ji :^m\m 
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¥&l #^E^Q. M^\:^m ^#m>1U A^eoPl ?]6fl, Aiui:^S ±^ xii^m^ :'f|j^l|5^ oimhi m^\^ 
n xm^ o\mm mii 9io\o\ ©iq. ^xii^ Aidi^oii s^opi ?|oh. a oimm n ?ixioii cueAi 
^01 oi^oiEjci. ^, oieoi 5H^=iQ. :?HAipr oie a^ib n :?HAii2i o\m ^2}m m 

ca^Ai ^ 7|xioii :?Hye. one #01 :?Hjyioii chs^ Aioi^^oi :?FA!^e ^oi oi 

M 6tii luse ;qioi*^o^Mi. Aidi^oii q|o^ :7Haii^ see xhoiof^ s ^go| 

^ ^Se. Olie M01 X\^m 7J^XH:>|(intercept) 0| M\0\m ^^^^^m, 0| M 5Z> 5^ 

DIM 3|§2i Xl|01(variable-gralned control)M Xll^d^^ ^9.^ 0\2\ QE 

^ m^9\ ^ ^se m^^' :^^s(guard)g Aii^sFb qi 2ibai. 01 :?hHb oie^j mms^m oi oi 

=01 Afg£|7| S SEb ^011 Se£|D1 DM11 SaS ?ISH jqiSSQ- 

0|^^0!|Ai 01^21 0|gmO| ^^^^ zp^ ^^^Sf £D1|ojO| ^^SI^QI. £ 

(sandbox)M 2|D|ShQ. ojojo| ^soj ^Sfb iHH ^T:^^ o:^e^A| A|^S2| UDIXI 

OS ^itFS 4- xisr^o^ ;aiois eyeei □! oiaj ^8 iH!^ ^^>::^¥ei/oii:?iiso| ^gg. 



SE 1^ eiEiiqioi^h §^ x^^(go^b oisfoiiAi ?oimb ^^Hj^iig £9. 

£ 2a SI 2bb OIM ^ 3 3h^i OHSAl^lb £A|E^ £0. 

£ 3a UiX! 3cb ^ ^gOII die 4^SM £A|o^ £0. 



bPi. 01 2Hxji xHifsi m^?i3 Ai^^ajoii qii^ai xfh^ m^^^ e3 moiiAi a 

^01J!Q. V(^\^ Dl^ CA 94043-1100. Mountain View. Garcia Ave.. 255001) ±M^ ^ a^0| 3SA| 

3 A^oll ojeH :>m& mshshs £joi §y ^soidi. xmfefb goib oi 5IA^oJ ^^Hso|Q. 

A. g!£|2| :?H3 

oimoiiAi. xm ^soii 5fg£j:ii g SAiiAioiiAi A^go^b ^ :'jxi2j ss^ei ^o\m saisna 

^Ai Jl^SCj. 

2f0|£ U(World Wide Web: WWW) * s ojeI^o^ :>H^§ Ai^ Ul^^iBOICI. 
•MB^^Xi •b ^£ 2|0|£ m LH011A121 #21^71 (AIS)^ X|^5h3 OHM^Sj Q^^g °i S 

'x\B\ mo\^ 3£'b o|s^o^lA^ jvmoii ch°^ gnf^^ioi! ^ish shoiq. 

A^H^ EUAICJava Virtual Machine: JVM)^ :'^^^^0|X|°} Xm b^0|e ^^o^b ^ rfSS 

AIIAIOIQ. DldOl dbHM^IlOl^ (UiSOII :'f^2|0|Bt3 EhQ. 

'ejoiMeiBl'b H^n^oii AjgEib 1^4^ een^^ St^oia. 

^£ 

^^Ai <y □^0I3SA|r6lij^ X19\ 5£|S>1(J.S.Fritzinger)2f 1 fij (M.Muel I er ) dl 2|oH ±^ 

<yi£ yi^b x^H^ oHM^ioii chsh ss^is 3:^1 a| :hioi^oii 9\m s.m^ ^m^^m m\^2^q. sb owm^ 
e o( >Mj£ «}^oii 4=ggcf. 21^011 01^ >ioii seopi ?ieH. oHM^e no\^m 

m^\mo\°} efQ. oi£f HM^DW, o\m oH^^ufsi ^^i^ s^i^g mmiJi xiimm ^ sib :hioimm m 

3USfl0fE> ^n:^. OHSSie :?H^SQ. AJgX^b ^2^^^^ 0HM5i2] Q^^£S A| 
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^^x^:7^ oH^^2i ^if^e ^^M^\?m ^ siq^ soiiAi. uim^i^m ti^m ^ 9i^ym 

^ oHP5doiiEl ^esiia oHMei^ioi>3oii^ ohsoii ae^e one^ioii eissq. se§^ 

IS atQ. D;^e^A^ ngsi ^?\\ ^ :Hlo|eg e^oiq. :>iioiM a 

8 Jisiehxi af^d. 9^xiu H^a^om ^ oHMei^loidei:'F oh 

XI ^ai^sQ. C4i^g2j A^gxp^ xiich^ ^ sib ^§oi x^B^ diai uioiiAi o^s sstioi sihhs 

ess S^OilH. iHH DHaCfojoj ^^t\X\ ^o\Q. ^^gh ^IS. 01 

a^oi aai ^se =?^m ^ si^^^ eisn dim ^mm:D. ^gm^ Pib sia^ 3!oiq. 

^ ^soii aj^ aiAii xm Ai^iiioii qs^ xfls^ J^e^ m^umE W\ ^soii ^ s^p. oi 

•oiqmioi^ b :'H^l qiOlEi si Mm^y\ Setlia :3H^|2| 

Oie 8 :iHXl|2J ^^^0|| CHt^ 1,^22101. 0|MS ^lA|2i A\^m9] fl^^OII 2]Sfl>Mb 0|SH. ^ 
5H^£|X| &bQ. 

*f3S'b ?m\^ ?|x|OJ| q]§^ XlAIX^oiQl, il^b ^^A|^^ A|>^iJ2J s^goii ojsjj 
OloH, ^ SH^SQ. 

■A1Ul>i*b 2H^| *f^2^ Ahg go| s^L4^ ;,||j^|o| Hh^o^y^ IH^SQ. 

^B X1|01!?D! 0\U^ ^^AKaudit) 5^ ^^A1 (monitor) Afg§ 4- SiQ- 0|^^ 

x\mo\\ cHE^ aeoi g^oi ;qioi£j9 oi^ n^n^s 6hm mx\x\ ^^q^ y\^o\\ 
tiQ. PMoii y\^m st.±mB t^^^^ se^ ai^ ast^moi ^ ^soii aei Dimqeoii g^^^ej 

AMI x\^ nHeiQS: ci|0|E|:?r :»h^Ioii tJ^sin. xii^^ eieiniioiiiioii ^jaHAiBi ^ nM\ m 

omm sssMi ^^ehs oi oiE|iiiioi>iOii gee gxiish^ ^ioiq. 

E||&^ 2H^j Itldazy object binding): ^^ IT^CSEb 0|M)b ^ S A| 21011 A1 . ZL^m goH A^H1>^::^^ 

SMI 4^ 2ib 2Hx|| 1,^^^ qjAllEIQ- 01 q^ll 2f§8 ^ ^gojj ^oy oji^qgoil 2|aH 
AH;'l(jntercept) gC|. 

OIM eH§(name resolution): ^0\B 0|e(^^S if^)01l Pit! ^^1 ?|6H. 0|M 6flS0| mQ-^ 

p. 01 oiM 5fi§ofi>Mb o\mm Am i^^soii cheai^ck ^ ^goj sx^^joi mi^LigoiiAi. oi 
o\m m^m xiioim^ y\^my\ ^^eixroii 9\m y\^my\m ^ ?iq. 

ai^Kguard object): 0|^E ^l^l i^SOII gjSJ^ ^ 9iQ ■ 0| y[E.B AMI AFSE|?| 

3 ^/^~ Afg^ ^Wl aSSP. 5E5^ Ol^B ^Sj>ie §moI| 2iQ. 

XJ^e :?H^|0|| Xll^Sj oiEimiOI^M ^SHAIdI SEI ^ SiP. HfEIAl. 2HX1I Xltr A|>iijO||Al 

se^^^P xfSM Msrn:?! ?I5H. n^^ xjgoii q£^ exii oi?!?e 2*^9 :?fljyi^ 2iemo\±i 
oil sx||o| 4^ o^q. ;h^I^ ^0|§! xmm Xljg^ oj:^ d^e^/^ ^ iqII £ 
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A\m ^oi ^^olE^ ^imm^^^m M\^m ^£ ^iq. x\^m A\^my\ mm, oi xmoi oimin 
^mm mom s^oi. oi oige 3 qgoii shs ^^o\ ^xHm^ ^Hj^i 

mm 

311° :?F^El 5^21 ms.^ a.±m ^^m^ a^goiQ. siif^y:?^ -a^moi ^Aii Ef 

s e^oii 2jotj oioH ^ ma.^ An\ a^moi oioii aja^ ss^ 

soil xi§!8P- 

^^^2^ LWnm m AI^OII ^OIUS gj^ JU§s StrCeager binding) M^Q. 

mm C++ ^nF^eib A\^o\ ^ nnim, o\m)^ ^^m n 

^mo\0\ SSg ^^ElCf. 0|§ g2| Oie 01261 Oie)0|X|E}. P 

^^^K)ii>*Hb oiseii^ Ai^iie e^.^ ^^a^ seoi ch^^si goon. 

2HxJ|(remote object)^ qsdocal representat i ve) SAi QiBj 2ttn\0\\ UB&Q- 

CHa 3lA||(proxy object)^ g!^ ^i^lIM m:^, -SS^min. sSslP. O^e^Ai . 

?\^m:f\o\Ji, ^^iMm ^2^, ^ oHs^ ^n] a[o\9\ 

Sfi^ mo. ^OIS *|^(0IM)0|| CH^f ^hxII il^S ^3of^ 3[S0| OIM oHS 3[§ 

Oia. 0[^^ £ 2a °! 2bO|| £A|E^ y^2} 0| M JlfSOll 2JoH ^^^Q- mm OlgoPI 

?isH. ^m\^ ^mm ir^s ©H^Ejoiof ij^s se^ oi^e ^om^ai mo- 

y\ ^xi£ e^Dj 3 §r^^ fi^£i^ ^^9\ Dmy\ m^m ?i9.m n §r^oii 

£1^ ^eims ^ :jh°i ^^oiti oig ^^^o| ^zicf. 5isH^. :>H^i^ ^§ oim szt 

(concrete name space) ^ ^^oj aIIM^ 0|g 0ISe 0^3^ SH^gA! 8f2iAIE^. 8H 

m cH^^o|[:^. phaii^ :>haii^ oi§ ^xhe^q^ ^§mA|DL 01 of^ sh^ e 
m sesiAi afs^Q. dim g^a^ om ^mm ^ gtouf. ^^aizi fl^iioii 2|oh oish^ 4^ sip. 
l«fl^. :»H^i2j "^s oiM szi e ^Aii *r^2i ?^3cf. 01 i^s^ SH^^ oiMoiia 
B mm esH setia:?! mi^oii ph^i^ s^si 2»cf. 2h^i ^^aizi esoi oi 

'^s oie s^^■o(lA^ xi^g ^n^^ dim ^zioiiAi ^gsi a&oiQ. 

2feiAf 

£ 2b0ii £A|^t 2^e]A^^ ty^epioii ofef n^m ^ ^ ^S^i of ^goiQ. 

y\ 2^eixpf 2^ n gi^^ s^oii u^ei oim sh^ jusm xiioimiQ ^ 

oiq. dig mo\, n^B m oim^i mmm ^m^^i^i ^§ oi= ^^tAi^ 4^ sick 

oiS mm :?^SaH:?ISHQ :?FSah:?I 5^^|X^M ^^^m «loi oimugo^ ^^c^. ^oy s^o 

^ »s oiM ^2}m "RMm^ ^B zi^m Piam^ nm2\ ?u!s^A| diji Afg 

1 ^ gtcf^ :?r§oil :?|2sn::f. :?^s*H:'l ^*^|AP^ 01 mmm m^m^ ^^o^|□^ ifssj «^ao| 6H 

SE 2boi! £A|5| d^2^ ^01. 7^^xH:'l ^siAhb oig mm m^o\Q, o\m mm 3f§2j m^2i ^ 
^1 y\^7swj\ =^§eixi u^u ^^^^ 

SE^ 01121^0^ exHa^Ai s^^Q^ m^\m ^^mQ- y\^my\ ^eixpoii ^m a 

E ^10121 mm 3|§2| ^iJ£Oii 2|^otc}. q g^si :?h^jui:'l 5feixj^ d{aii 

01 o^y aisi ^^oiiAi ^ siQ. ngoiit M^m^i ym m^m ;qioi^ oi^si 

^xH«fci. y\s.^}iiy\ Sfeixh^ :?Ha|| o\m, ^^xi :?H*ii 01^ si nm^ cilo|E|2f mB E^^^ El^^ 

^ SSiOIl S^t^Q. SE X^10iS^^ o^cq 3^011^ #gS^X| XF^SI A^gg 

TIM ^^Afoh^ ^01 mQ.m ^ 2!Q- 0\^B xr^OI A^gEI^I 3 5tl/9E^ ^dl OimUM2| 

Q^e q ^#1^ ^# 0I2J mB ^mt: y\^^\Ji me\m. y\^m\ ^aixjoii s\m t^EJi ^ 

y\^ 

^ g^S2] sEp^ <y§Hoii 01= ^goi :7^c ^xiib mm 2tt7^\ ^tfs^Di. :?^si^:7| 5^e|x^:?h ois:hi 

a^E 2Hxii A^gE|:?| 3011 m\\y[ s.m^o\ ^^x\ ymm mm o^ff a ^(argument) 

Oil cHoH aems y[E. ym\ 3011 ^xisaciia ^^o^sa. Ef^E! ^aii ^rs:?^ 

^011 2S!^p^ a#£iot. Dl|A|x^7^ w^^Eioi a atoii gems 2*1x11^ =^xi ym\ 
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OI^OII ^x|£joiqji ^^oiiiq. £ 2b^ 2H^\y\ 4=S3 fTSg y\^m:f\E o\m SHS 

?\E. ^mm m^:f\ a^s. ^^oi s^^^^s :?^^AH:?| sraixpi A^gg^ Bm^^ saaj ^ 

A^m:>il. se^ E^^^m. ssoii chsh ses^q. o\y\m^ o\e. ^^xi 

-2.mm ^^o\x\ esfAi^i^ ^. 

-s.mx\ nn\ cm aeiM si/se^ SA^6^b ^. 
-see i^Aim^ ^. 

-Af3 ^gsj ^ejg >i. 

-g^M ^^Ajo^^ 31. 

-^Xl Si/5E^ alTll ilAF Aidl^iM ^^ehCf. 

:?^H £E^ ^^Al. ^ :?HA|f ^ :?HXI|OI| 2|SH SgT^^AI Sf^PI. 01^ 33101 7P 

2^eiAK)l| 2\m 2I¥^¥E1 ttH^OIP. 

^^Ib. 5E^ :JH:^|01| ^ 4. 0^:3 7^^xH:?| 5[B|Am^ eiPi^ :>\ 

^sjE! 2HAii i^^m ^mmmo] gjeiiej ^ ^iq. 0121 ^sh^^i g^fSAi. 01 «^ 

3 QMoii A^g^ cHoii^ QAi EIU3 oiM mis §y &^\x[m 01 

01^ 3ioiq. 2^^lx^^ ciAi n §*4ioii oFei ois 

M 3>^Q. 2Hxll «oHg^ ^^S 5H^^ QMOII ^ov ^^o\ ^^\^ goQij oa^ 3!0|p. 

^^^^^ ^Ait^ 113101 mu\^ s.^^^} §jzsoii ^^sio\ ^y\m mm^:^\m qan 

^^01^ SHOllAi ^§ 2H^|g 3^0|C|(0|0i| CHaHAi^ Ol^OII ^M\m 312J). 

1995t30]| Prentice Hall International A\y[ Zt^El^ Modern Operating System' 0| AhSOIlAi 
e^y|t^^s(A.S. Tanenbaum)0| ^0| . QE^ M\ StJ^ 4- 

(1) 2!|*II0II Clle^ XlAIXKpointer): ^fiSh X|A|A^^ oH^^ m^)Oi\ 2ioH ^?l9Ct. 

s^ x|A|x^e ^Hjsrs. m^m^ m±^o\ s.mm yy^^m y\^mQ- oi3ie 

(2) 2HM\2\ fi^S ^^igcf. ^ao| sfgsj 

(3) ^H^ioii me ge aei: ^si^ :^\e. ^^ioii 2Joh ^^^a. 1131B ^e\m 3A^ 

4^ 9111, :»Ha1|^ ^§ A^g5^:?| ?|sH xll^oHOf siq. sesv. :»HaIPF 

2t!j5ii ir^a^ ?\s. ^mt: ^mo\ ^Mom^} e^shxi^ &*q. ^xis ij^h ^iij^ie ?oi£^ oh^s oimb 

aiAjj Ai»f Ai^^'oiiAf2i fisM ?i5H ;tlle^^ Qm m mu o\^m ss&hP. 3*1^11 

xii^ nHeic|o'e ^xii ^ n ^imm^m mm x^^ol| Q\m see ^ Aiioim:?ii e^a. ^xiib 

:'HAiioii oie T^ioiM esH ^m^o\ nm^ o\m^ :?\M^m mo\§vq. :>m\y\ m 
u\^^m m ^ aiQs M^\±m ^mm ^ a^Di. ^mm :'^^^oi gioi x\mm M^m ^ 

^ 2i°Di ^^^^oji ^^^otp. :)my\ v^ejxi s^i^t ai^^^ei ^ 

^£ 2i^ai. n^B ^mm ^ :'Hxiioii ^^ ^'Ul^oixi aro[fl ^gem. a^^^Ai. dii^ 



8. 

OimoilAI S ^Sdl Sei Wmuesi ^^0\ xm ^^mM 6H^:?l(interDreter) 4!S 

Aiei qomeiBJ^ 5&^S^^ Xm aiAl(Java Virtual Machine: JVM)0I1 CHSH 01^015! EE ^^011 CH 
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JVM c 2jaioiiAi2^ zi m9]^mo\\ ^^m 5!oiei:ii :^^s^^q. xiof ejoioij ai°^ s^^ei 

XliAl ^ JVM0||Ai2J 1996^^011 Add i son -Wesley #^^^011 21oH Zf^@ JI^^(J. GosI in) ^ ^ai(G. 

Tele)OI| 2J»i The Java Language Specif Icat ion S§!2j s|cm(t. Lindholm) SI WE 

(F.Yell in)01| 2|oj The Java Virtual Machine Sped f icatton'S}^ SH^ *t|Ol| y\^^0\ 9iQ . ^ 
21 DimU^SI S^M^ ^I^CJava Development Kit: JDK)) 1.0.2 §J JVM2J 

Aix bisoii y\^mQ. 01 SB Ai^in MeH^s Heis Ai^gj xr^£i £4:011 cHsH ?\^^Q. xm 
cH^i^ ^m^. ^^2.^21 M:7nii5ftxie>. y\^m 2} m^^^.^ ^xitiEici. 

Bi. no. 

oiQ. :>Haiiei^ eoi^ ^eH^oil ^goPi ^oH ois ^o\\m ^^m\o\ ^S£i2ici, ^eH^^ n^oi 

s Ai^ii ^£H^# mm s^£i:^i ffH^oii. MeH^b esmxi s^m m^m ^eis o\m^^M 21 
q. qe^Ai 01 x^d^ £ioi^y£i moil mmi^ m^^m s^E^q. oim mm Jimiom 
if3s)o^¥Ei Mm^9.^ Ai^2j A\^m ^S2i ¥^011 z^m ^ 

Aixmip. II^a^Ai. 211x^1 ir^^ ?i^ioii cH§h xi<i^e si^sra 9io\M ^^sb ^ai 4^ 

eeH^2| M^b 0|s gPha >.§&^o^Jifc| CHg^ XljOie WSfl ^^^Q. 2Hx||o| »g 

0|M ^2}0| 2Hxl| *f3se Si^fiqg «/^oi| qt^ a^oi m^i^Q. m^\M y\^Oi\M 

Ai^si^oi. H^a^B ^^1 m^m o\mm ^ si^ xf^Moiiei ^^m ^ 2iq- ^haii^i oim 
e ;3ioio^:q 4=Sopi ?I5H. ehs^ oimue ^ o\m mm^ m^ti ^01 y\^my\ ^^^m ^ 
EJl^o^^l ojgEiq. ^^1 ifisi ^E^Eiq. se«2j «^^ol ^^£i:?i soil ^aiim ^ 

mm. :?iae ^?tis m^\m oitv ^a^m ?bi6t£^ ^s^q. 01 7i^g 

?ISH. qM3f i^e ^ 

- oie as. 

- X^tl^ DiAIOll SiO^AlSI ^# fl^oj 

- seHsj c ssoii sesfe :7|«i eefl:±i. 

- 

y^ DH¥ gamq. 

B2. X^H^ 01 Al ^3-A|^ii aip 

01 ^e^oiiAib x^u^ cHA] o| xjH^ 4»^Aiei efoiaeiei2i ^2|^^q. ^ai^i c ^hoii 

M ?^£ioi cae^Aj oiAj 2i^^oiq. ^ ^soii ttfM aei oimqee ^^ms^ qe s^:. ^ 

- y\^ oiiMoj 01 M oils 9^^, 

- ^^o\^ op SH(opcode). 

- 01|£a01|Ai2J 0151 . 

- ^(thread) 

y\ aSEISiq. 



01 e ^z! ^§ 

^xiie n s^i^ai xim ase ^^spi mm, ^m\s] ^§ dim ^21o\ 

^|01£|:3. 3^01 ^^£|>iq s^x^£lcf 

AK^of^ ^xii2i oiM szte ^-sm:?! mm, xm^ ^-^m mm ^^^oi oiggq. xm9\ ois 
aioio^^B qe ^21 i£ii:i:. ojq2iioi^ °i zi^2| gH. . m^o\ ^o\^ oie^ 0|g6^ 

01 20IIA1 U^thQ. Hhgoil UieH. 0|M §J^b SE^ 3 XPi^jl^J 01M??d> 

o\uek, n SE^ ^^m ^?io\^ eiqmioi:::^ o\mm h§ sasi 

si^Ehq. 2H^pj Ahg^ ^ 9iy\ 3011. n oimoi sh^eio] %'^y\ ^o\o\ m^m. ^^xj^ 
MX! sg£|Di. 11^:?^ A^gsjs q a^e^io^ x^£i^ 4^ ^I'b ^S^^i ^h^^i 

§J3SS iaAHSq. Oi|£|;>J ^:^10. 01|2|:?F OIOII CHSHAi^ igget^Olj Addlson-VVesley #^^A^01| 

^m la^^KJ- Goslin). ^01(8. Joy). ^ai(G. Tele)01| 2|o^ The Java Language 

Specif icationOIBI^ SSH| ^ °| ^seM(T. Lindholni)5[ (p.Yel I i n)01| 2|o| The Java Virtual 
Machine Speci f icat i on ' Bf^ S^'2| X\^m Sq. 

oieoi 2H^| 6H^^ ^011. :'^^xH7l 5^e^x^^ ^#eioi §^^2i eHSoi m^s\o\o\^ o\^x\2\ 
o\^m ^§l^q(£ 4e ^). qeiAi. oie aHse y\^^y\s\ii, (^^\M ehb! ^^i ^t^oi oi^ 

0i5!q. y[^^y\ ^^^|x^2| gjtoii qe^. 0|M 5ei2| 4^so| q^dj :?l#o^b d^2[ ^o| 4^^s 
q. 

:'rS*H:?l ^^B^X^7^ 'Tl^l Oietb ^^^m mS. NoClassOefFoundError 0ll£|:7t il^jSEIOi. M^:^ ^^0\ B 

XHsrxi s^^q^ ^#£^ 2t!*lloii:HI fiAie^q. qsjAi. mm^ x^g2J oiee SHSi 4^ ai2 S3f^ 
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o^. sHs ^^2^ m^x\x\ ?^^Q. ^eJixmm o\o\Ai oi\9\m jgi^m^ 

01 2H^|2| ^§ o|M ^^im m^^Q- 

:^\^m:f\ 3Bixf:?[ ij oiei^ me. s:#oi mm o\m 

01^21 CIS olS SH3 :?l^oi| ^£JS ^t? a^M o! c ae 

(1) ^n\m ^feispi ma.m 

(2) fi?o| §H^oi xioii qoH ^Mmo\. m:'f£ixi p^o^ aisH^^ HAimia 

(3) ngxi afODi. ^ae §h^^ haisjs shsi 6h& ¥Moii qt^ xiaix^s c|^Alls^^ ^ 

:?^^AH7| ^[eixpr « JW2\ 7\E. Amm ^ n^m, &a s# oim mm ^ei 
omsF 4^se ^oiq. 

3S Cl 

ic_CheckMethodResolving()methodOi| Xll^SLKOI 3^0||A1 :?^H 2h^1^ HEi 2Ha|| ' ^ ^ei^CI). 

[mm ^'^] 
I* 

*/ 

ic_PrepareFi I ter(class. mb): 
/* 

01 ^§ oiM sH^oi s^7^El^x|2l o\^m SA^s^ 
*/ 

if ( ! ic_CheckMethodResotving(nib))( 

01 grasi oM\^x\ e^o^ diohss sAi*f 

*/ 

f ieldf Htertable(&mb->fb)->resolved = FALSE: 

return FALSE 

} 

/* 

mm^ haiit 

*/ 

f ieldf i I tertable(&mb->fb)->resol ved = TRUE 

*/ 

constant_pool [ index] .p = mb; 
cont j nue_as_usual () ; 
[...1 

w\ m^:>\^ oim mm^ ^^a^i u^m ^^^iq. ^^aj ^^^^i ^sj^ 

1996t301| Add i son-Wesley eS^A^O|| 2|Sfi ZtfHSI B|^mM(T. Lindholm) ^ ^gl (F . Yel 1 I n)0|| The 
Java Virtual Machine Speci f i cat i on ' 0|ef ^ S§j2| *i!0|| :?|#E|0| £ 4b a#2| Xi|0| 

# saimol £Ai£[cf. £ 40IIA1 g &SOII 2|5H 10 df? fi^b 19-25 

27-290IDI. Sibb SeH2J fi4:0|Cf. g ^Sdl CCF^ Ajf? fi^ib Ojg SH^dl 3Af SI 

op^sb >Mi^2i UEjLHb mm mo\^M ±x^o|c^. a^ie UEfyq. oii 

M gOi. 71 q opc.invokevirtual3^ S^^Ejb op 182 (Oxb6)b '^\^ S^SPl 
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op ssei =pgjoi ^seq. ^mm c«Eh saw n^^i shm 
:?l^oi ^s^Q. D^xi°[ :7hH ^011. ^e«2j ^^oi ^^siq. C2^ s.mm m^m 

^ op Msoii t^^S c as ^Moiq. oi as amoii 

y\S, 2H^|g 2h;5|| ^^3soll ^^^o[?\ ^oH. gdH ^^a2J lH|e£| a|0|0^^0| 
¥^ C2 

01 3.^ sen soil t^gJSQ. 

/* 

^x|£|2iqs SE1 aixiph ^x|£|oj-x|2| Oj^M SA^^^ 

*/ 

if (f ieldf iitertabte(&mb->fb)&& 
(f ieldft ltertable(&rab->fb)->used_f i lter)){ 

/* 

^^o\ s oimqgM mm mm^^^m 
*/ 

if (f ieldf i ltertable(&inb->fb)->resotved == TRUE) { 

/* 

*/ 

ic_l nvokeFi If erObjectsCf i etdf i i t er table (Si iab->) . ee) ; 

} else { 

/* 

01 M ^2im 3Ahmoi ?[^^?\ m^x\ ^mm 
*f 

i c_CheckMethodResol ving(mb) : 
} 

/* 

SE ^01 ^ £l2i^:?^? o[^£ disie xii^mxi 2&?im 
*/ 

if (except ionOccurred(ee)) 
goto handle_except ion : 

} 

cont i nue.execut ing_origtnal_method() ; 

I. .-J 

2H^|oj oio|oj uhgg Aj^s^:?! o|^ at^s oiieej lhoii oH& 013 s^M ^^q. ^^^2| om 

H^B §^ fl^2f fl^S qyq. §^ fi4i^ 12^21 MCH^ HAJ2f S^^mill. 

fli^ 12^21 st^E^q. UNIX aI|X|| LHOllAf :?^^e^ om Hg2j ^r>.e >y|Zl0e 

2f aioiEf Aiina^^ :?Hyo|[Ji. ^ Aiiaae^ oiHai>^ ^^^21 ^^o|§^ g^o^ qgti^ai. ^ 
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^ fi^iM fi^(f ieldblock st ructure)01! ^^^Q. CCfajAi . 

g^^Hb ¥^^9 oi^ ^^ ^hxusi ij^g xmoi ^om ar^ ^ijjtii 

SetM m^^^ y\B ^HxllSj HAIo^^ ^4^(res_f ilter^ H:7|£lbai. res.filter^ used.filterS 

^^^01 oti^E :ii3Ei^xi o^yxie SAim^ MeHiKresoiveds s:?i^). 

eeWri^ HfSJOII CH§^ XIAIXKcaller^ H:>|g)£^. 

^ (^Ah^oi 01^^. 2H^|^ LHOIlAi 1£| 2l|x||S MBI^q) 

¥^ C3B oliqo| ip^g SEAIelQ. 

¥^ C3 

^^H2J SIIGiOlQ. 

struct filterdtable { 
int used.filter; 
int res_filter; 
int resolved; 
struct methodblock *inb; 
struct ClassClass *caller; 
struct filterdesc *f liters (11? 

}; 

filters^ S:?|£ib 0\^\0\ 3.:^2\ C40II £A|£|bq|. H^S Q.±' 

y\E. 2Hxi|2i 2ijxi| oilSBi ^x\o\\ qlo^ x|Ai;^Kobj^ s:?l§)2[. 
^#£|OiO^ m ^asj OlSCmethodnanieHS fi:?l§)JU. 

^ ^aoi ^^sf 0|gg ^^XIEI ^^0|^^ M^m 4= ei^^ li SHS AiS 

(signatured S:7|§), 

b e& S(notlfy^ 
¥^ C4 

^q ^^aollAiei Z| filterdesc2J ^§0|Cf. 

struct filterdesc { 

HObject *obj; 

char ^signature; 

char ^methodnane ; 

char *notify; 

); 

y\E. ^mt: kh^oii. oi^ o\m szi ai ¥^^sjb ^moi\ mt^ sxH^ej 

DICK tt^^^A^. mspi 9|8H HOII a:^^^ ^(executing thread) UMX\7\ M^Q. 

4 SiCI- ^ :?Hyoi| 5^©! ^^A||°l ^2jb 19891:5 1^ 6^ qx|g §U|AKOigital Equipment 

Corp.)2| System Research Center (SRC) ReportO]| d|^(A.O. Birell)0|| 'An Introduction to 

Programming with Threads' ef^ Sl!2| XFSOII U^Lf Siq. 

^ ^SOii qe AM\ ^ yis.7^y\ ^^^|x^b A^b^d ^SSq. oiMSSEe> 7i\mo\\ aeepi ttH^oii. 
e y^soii ccfM Dii^Lieoii ^o^^ 0.^2^ n^xi a^e s^e :'i^oi ssma. 3^x1 

8fo0. x\moi\ gem^i oioiAi oHo^q, :'^dj^H:'l ^^elx^ x^d 
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01 aA^t^p. 01 ^^^^ ^mm sAime aioig ^ siQ. ^oi ee^ y\s.tJi\y\ ^E\x[m 

mo\ym, ^^ ^mo\\ 91^ HAi^cf. Qgoii ^oi 2Hj^ii se^ :'fsxH:?i ^reix^oii mo\ 
y\:^\m Aisms ^01 ^^ ^mm 21^ ^^^m haieio] ^^x\ ^a\^q. 01 HAp^ 2i^xioii 

^^AlZt A|>b^^ yMiS^ mi^lLieOil ^01 4- 2ibX|2| d^g SSH^Cf. ^0| :^FS ^All SE^ 

y\^my\ cqus x|A|x^^ xmsiQ. 

01 gjAi^ Ahqj^. Ai^n s.mm ^jsoi ai^oi ^ssfxi afsiict xr 

soil 2ib ^et. ^^EH7^ 2[§oii ^Ai^s^ 01 m^m =F^Hiii3^Mi n^se m 

XlPf i^^m^ XF^OII cm see ^^P. A|:^tiJ my IH. ^3 ^^£fl^ Xl^^ip. Al^ii 

:?Hy2| ^UllE.^ 1996^011 Add! son-Wesley m^MOi\ 2ioH Z!|hsi aieei(S.J. Leffler) ^011 

'4.4 BSD UNIX Operating System'OjBF^ S^'^ ^0|| y\^SiO\ giQ. 

Si &bixj^ ses^ ^ai^e oiioieioii ge^ ^ si^oi saiiei ^mm xiisg o^ffsj 

2stxiP^ ^01 seH2| Hdisoii qs^ xiaixk)|| sai^o^ trsSQ. ta 

Ai. MB 2ijxiioii ^^mn set^Q. 

- ^01 ^^EII2JX| OmXIS UEfLfl^ B|e(sv_threadS H?|g)2L 

- ^^SOII ql&^ X|A|XKi v_f i Itertable^ 

- ^£H^ ^^^^ ^Se.^ ^^ HaigiOII a^o^ x|A|XKic_optopo^ h:7|^) 

m ?uim£^ ^^^Elbm. 01 fiib^ sa^ ^oi ssss[ afoisi s:jng :?fsxiM ch 

x^b^ ^£H:^ ?ii#-AjgxF ai^ 

01 ^oiiAi^. xm^ fi:4^oii Qm y\^mQ- m\^^ ^21 m^umm xm^ x^u^ 
^o|oj goj ^ ■:^f^oh §f *q|^ >^ 015^^ m ^mQ. 

m^M, Cfl^^SI ^eH2J C 3S0IIAI fi^OII CH§! ^ §2|S £]E|1H|0|^M 0| g5^0i x^y^^ 

Ol^OiSP. geflSj C =?^£| Intercept ion InfoS MB|^ fl^f ^eH^(abstract 

base class)M ^811 4^ SIP- 

:?h^^:'l §M 

Interceptionfnfo^ X^d^S fio^ ^efj^OIP. 115!^ ^ ^S0|| OfE :'l^^ JQI^o^^QI 0| 

X^bK)ljAi^ MSH^ 4=S7|(class modifier)0|| 2fS[ ^^2]^ S^A| o|gs| ^o|i ojs|| jji^s) 

- oio|o| 2H;^jo| ^^j ^ei^ 

- oiojoj 2HxI|0| X||:H 2^B|. 

- gJ2j2i omej^°l it! 4^§. 

- 2H^|/:JH?^ll2j. 2H^|/:?Hx1|2| m^o\ ^o|£i oiM 0|S ^ A|S 0|M^ 
^ U^OI ^ 4^ 2iQ. 

Intercept ion Info ^CH^OIj 5|o!l X||^£l 21 E|ff||0| ^(Appl I cat i on Programming 

Interface: API)2J ?Hfi^ CSOfjAi Xil^gQ. ^ ^^gOII 0^^ #^E[ ^21 y\^m ^SH. 

:'^^AH:7| 5faXJ MeHi!i ai 7JH 0| Interceptionlnfo :7|«^ MEfl^e £A|^^ bhS^ g^0| AIM 
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public abstract class Interceptlonlnfo ( 
protected native void unresolveMethod ( ) ? 
protected native int get In t Argument (int Index) 

throws ArguinentAccessException; 
protected native void set Int Argument {int index, int value) 

throws Argument AccessExcept ion; 
protected native float getFloat Argument (int index) 

throws ArgumentAccessException; 
protected native void setFloat Argument (int index, float 

throws Argument AccessExcept ion; value) 
protected native byte getByteArgument (int index) 

throws Argument AccessExcept ion; 
protected native void setByteArgument (int index, byte 

throws Argument AccessExcept ion; value) 
protected native Object getObj ect Argument ( int index) 

throws ArgumentAccessException; 
protected native void setobj ect Argument (int index. Object 

throws ArgumentAccessException; value) 
protected native void print Argument (int index) ; 
protected native Object getClassLoader ( ) ; 
protected static native String getCallerO; 
protected static native String getCalleeO; 
protected static native String getMethodName(] ; 
protected static native String getSignature( ) ; 
protected static native boolean 

pushFilter (InterceptionFilter arg, string f iltermethod. 
String f iltersignature* 
String ic_jrianager_notify) ; 
protected static native boolean popFilterO; 
protected static native Object [J getFilterList ( ) ; 

> // Class Interceptlonlnfo 

si^^igidi s^oiBfia yi^^:f\ 

Interceptlonlnfo y\± M^^m M^M^^m ^Q- S^o^b :>m^ 0|M ^Zl^ ^qiOiSm 

a^e ^bcf. ^# o^m^noii^m ^voie om^^ m^oiE 

8101. ^ oHM£i^ioi>3Jif 0HM5i2i =^m gioi. xm ^soii Qim 

DilSe] oPl ffH^OII. 4.7i(garbage collection)^ ^\M^ ^MIM ^^^^0! Wl 

a£ie yie ^^oi ^q. xm ai^oiiAi q o\^^ e^srxi s^oii u\a\^9. 

s ei^sp. ajBfAi ^^eix^b a^oi Mnm eb ^M\m ^^ ^Mmo[ mm. 

3^:hi om 8^^g oiiHeig b|o^ so^oii oi ^mm m7\m mm ^o\o. ^api 

oil p\m ^M\m ^2ib eiet.^ ^hm^j ^hoiiai Adi^sjcf. ^^e|x^b ^mm ^-^m 

11. oij= 2i\M\m oii= wf^oii ^^mo^ m^x\m m^mQ- asix^^ ^n\mo\ ^eH^j ^ 

a 3 ^011 ^/HM XISoFQ. 

InterceptionFilter M^H^b ^aIP^ Q^mb :'l^ :'I^M Jiai^s^P. 1131^ :'^^jUi:?l 5^BIX^2[ ^ 

s geH2| C ^^aOfl aeoPI InterceptionFilter eeHi!iM M^m^^s\ 0| ^BH>ib 

M^m^^^m^ ^le sbh^] ^^^(zI^o| ^^^e ^^i if^)o^¥Ei a x\mm ?ii^ 
^S^ElQ. MM\ ?^^oiiAib. ^x]|b ^eH^ ^^aoj ^#£1:^1 ^loii ^n^p. cee ^1^ 

^ej m^:^m ^o\mQ- defauitcaiiFiitero gr^g 2H;^ii s.m^y\ soil 

s S#E|^ ^^aoiq. 

jas C6 
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Ol^e Intercept ion Info 3.^ W^Xi^m STSt^q. 

public class InterceptionFilter- extends interceptionZnf o { 
protected int unresolve; 

private protected InterceptionFilter ( ) { 
unresolve = 0; 

} 

private protected void defaultCallFilter () { 
throw new ICFilterBxception("no filter method 
implemented" ) ; 

) 

private protected native void detachMySelf () ; 

) 

^ 3fsoiiAi gcHel am:'^ oi#ois:a. ajj^ii^ s.mmy\ ?i£h s# ^FsoiiAisE ^c^|^^ 
siacf. ^xii^ mom. gixF§Hg|5jo^ nei:! >d^^^^ oim mm 3f§ goii ^ 
o^AM oini ^#011 cfloH se^^B es§ ^ :?fSxH:?l 5f^lx^2^ 3h^| 



Oie OimL|g(naine resolution mechanisBi)M ?U|6^b PIO|E| H^Ail^ A|^«l. Lj|^?|3 

A|^iJ0||>M2J. OIIM mO\ SEb :'|Ef 2i|x||2f (2a 2n)e SeHS^&l SSSPI 91 

Xf^ fi^ a^SO|| £lOi>M. ^^:?l X^^^ XII 1 PH^Kentity). ^ :?H^I (7)011 2|SH aMIil ^^:'l 

A|^^«i LH2] ^1 2 :iHa||. ^ S#£]b :»H^I(9)0I| 2|oH Xll^ei ^OjOi. 

Xf^Oil C«o^ 0|M(syrabGlic name) e 0\^mO\ ^m^i^ :?||jUI(7)01| 9\m 

S#£|bPI. (^y\M 0\m 3xllb nnim Oie S2.Kpresurned name space)# 

DIM mm oieoii choh mm\^. o\?\m ai^i x^ 

gjg ^^SStb :'HAi|01| qjoh oiM SiKconcrete name space)^ S^miQ. 

semb ^jhaik?)^ s.m^ :>m\is) lhoiiai ^^:?| oie ^21011 cH5HA^°^ see 



01Mb ^oi£ :)Hxll oigju o\mm sijmbai. ois Sxilb o|g 

g^mb 141^^3 A|:^^^0||Ai2| - 



3 

«l 1 H mXl 2 ij e Oliz: S^ iJOll 2iOlA|. 

seoi eig£is. dim mm 3}§b :?h^i(9)oiiai mm^ ^ae ^^shoi gohb 

(2a 2n)0|| ^^^^^H, S^o^b :'Hxl|(7)21 Q^. ^5it^o| ^ o\?\o\^ §f3S(6)S 

01 MM mmm^ ^ti Ai>ii!oiiAi£] x^g 



XII 1 1^ mXl 3 i^ § 01^ m 1/Oil 2i01>M. 

m 4^§§^b mt* ui^9i3 Ai>biio!i>M2i xm as 
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5 

XII 4 ifOII 910\M, 

xii^mia s# wioim^ m^?i3 Ai>i«joiiAi2i ^^a. 

^=?t>^ 6 

n\ 4 i» 5 i>0|| 2iOiAl. 

2H^|^ 2Hxl| S ^0\\ ^#£|^ m^m^ A|^^0||A12J x[m ^s. 

^:f\ ^MP\ aeoL Di/dl ie^^ai ^^ti^. ^ o\m 3|20i|Ai A^g^ nf^oii hi 

XII 1 ^^ LflXj All 7 ^ ^21 Ofi= SI gJOII 21Q\M. 

^^^21 ^oi£ omsj e:>lP^ 2«!xii xitf ^^^o^ m^^ia Ai>^gjoiiAi2i 



§?t^ 9 

Qioi&i x^ej m^?i3»oiiAi2i. oiiM eol iif^ Mmi2^ 2n)m se^^^ 

El SsePI 4^BM XllOl SxjOll 2iOlAl. ^^;'| Xh^e X|| 1 :)H^K 

^ ^mm^ ?mii)m ^sh ^m£i:3 um^i^ ui£i m 2 :?h^i. ^ ^m^^ jmi^)m xjis^ 
a e XII 01 

^^?\ s.mm^ :»H^i(7):'^ ^^:?l x^mm m^i ^em ^mm^u\ M^m^ 01 mmm^, ^^s 
o\m mmt: nMm\ 01 e ^e^M m^m^ 01 m sh^ 

2| oieoii meH 21*^11 ^sohsi. ^171 ^j^ii ^n\^ x^^g ysm^ 01 
M sztM g^mia. J^^B x:fs2j st^ei 2Hjai 

^^:?l a#£|^ :?H*1I(9) LHoiiAj 01 M ^Ztoii cfl^i ^mm^ :>m\0)9\ xi|*io^^ m 

e piojEi x^e| uie?i3oiiAi2j xiioi sxi. 

10 

xii 9 »roii 2ioiAi. 

^:?l Sx|:>F y[E^ ^M\03)m ^*ieHQ ^:?l ^xii *rs(6)e ^Mm cflst mAiim^ 

^ q st^m^ aioiE| *|B| me^aoiiAi2i xiioi sxi. 

11 

xii 9 §f 5E^ ;gi 10 i>ioii siojAi. 

4=3^ ^21 a|01£ 2*!^l Xltf ^i<^2J rtiHe^llOIS ?el£i^ C||0|E1 m^?|30l|A12| ^ 

E xiioi Sx|. 

^?i>^ 12 

xii 1 m LHxi :qi 8 m e^j oii^ oh tt^s^ SJ/5E^ ;qi 9 tT LHXj ;gi 11 esj oij^ m i^e 
Ofs^ Die SHS A|>bl!0| ^^Eib qiOjEi xiei U|e^3. 
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